1. Technical Field
The present invention generally relates to multithreaded programming.
2. Related Art
Threads are used by software developers to enable concurrent execution of sequences of instructions. One way that software developers have managed access to devices in multithreaded programming is through the use of wait states and wake up calls. When a process needs to access a device whose state is busy, the process state will be set to the wait for x where x is a value associated with the unavailable device driver. When the device is ready for the next process, it issues an interrupt that invokes a wake up function. The resulting wake up call will change the state of all processes that are waiting for the relevant device driver. For example, the wake up x call will change the state of all processes that are in the state of waiting for the device driver associated with x to an executable state. The scheduler takes note of all processes in the executable state and will select the next process to be executed.
A problem with the foregoing management technique is possibility of a missed wake up call. A wake up call can be missed in the following scenario. A first process P1 accesses the device driver and begins using the device. Then, a second process P2 accesses the device driver, finds the device is not ready, the state of process P2 is then set to wait for the variable associated with the device driver. The problem occurs when the device becomes ready after P2 has found that the device is busy but before the state of P2 has been set to wait for the variable associated with the device driver. It is possible during this critical period that the device will become ready and an interrupt will invoke a wake up function to wake up processes waiting for the variable associated with the device driver. A wake up call issued in this critical period will not change the state of P2 because the state of P2 has not yet been set to wait for the variable associated with the device driver. Accordingly, the wake up call is not effective for P2 and P2 remains blocked.
A workaround that has been used for multithreaded programming in a single processor environment is to turn off interrupts before accessing a device driver. Since wake up calls are issued by interrupts, turning off interrupts prevents wake up calls from being issued. Therefore, turning off interrupts before accessing a device driver prevents a process from missing a wake up call because its process state has not yet been set to wait for the variable associated with the device driver. Of course, interrupts are later turned back on.
There are problems with using interrupts as discussed above. For instance, turning off the interrupts decreases the performance of the relevant system. In a multiprocessing environment, turning off the interrupts does not avoid the possibility of a race condition. Turning off the interrupts for a plurality of processors in a multiprocessing environment is likely to cause an unacceptable decrease in the performance of the system.